============================================================== Guild: wafer.space Community Channel: ℹ️ - Information / general / Using gf180mcu_ocd_io in LibreLane After: 2025-10-31 11:59 p.m. Before: 2025-12-01 12:00 a.m. ============================================================== [2025-11-26 2:14 p.m.] 246tnt Creating a thread to avoid spamming #general 😅 [2025-11-26 2:18 p.m.] 246tnt And I also can't creae issues on the `gf180_ocd_io` repo because issues are disabled on it. [2025-11-26 2:23 p.m.] mole99 Actually, I think there is no reason. I simply wanted to do it like the SCL library where you can just select a different one and all the views will point to that one instead. But the PAD library is a bit more complicated and just selecting a different one does not work that well. [2025-11-26 2:28 p.m.] 246tnt Well having the `PAD_CELL_LIBRARY` is nice. But ATM some of the config seem to be set in the base file based on replacing `$PAD_CELL_LIBRARY` and some config is set by loading the subdirectory tcl file. And I think putting it all in the subdir file (possibly still using `$PAD_CELL_LIBRARY` so you can easily create new config for new IO lib by just copying and patching the little things needed. {Reactions} 👌 [2025-11-26 2:28 p.m.] 246tnt Now I'm faced with the much more annoying issue that OpenROAD is segfaulting on me during GlobalRouting 😩 {Reactions} 😵‍💫 [2025-11-26 5:12 p.m.] 246tnt 🎉 Found what OR didn't like 😁 {Reactions} 👏 [2025-11-26 6:31 p.m.] 246tnt ``` 292 Magic DRC errors found. 47 LVS errors found. ``` [2025-11-26 6:32 p.m.] 246tnt The DRC errors are in the corner cells and looking at the upstream repo, I think @Tim Edwards already fixed them a few hours ago. [2025-11-26 6:32 p.m.] 246tnt The LVS errors look related to the analog pads having DVSS shorted to ASIG5V ... {Reactions} 😶 [2025-11-26 6:39 p.m.] rtimothyedwards_19428 @tnt: I've been chasing those errors all day long. Hopefully it should be resolved by tomorrow. [2025-11-26 6:40 p.m.] 246tnt @Tim Edwards DRC or also the LVS one ? [2025-11-26 6:42 p.m.] rtimothyedwards_19428 The DRC one. I should have time to look at the LVS issue but I was previously unaware of it. The DRC issue has been bugging me for a while; I just needed to find some time to work on it. {Reactions} 👌 [2025-11-26 6:45 p.m.] 246tnt Ok. I'll just wait for the DRC one and keep digging on the LVS one, see if I can find what's the cause since it could very well be something on my side that I screwed up ... [2025-11-26 6:52 p.m.] 246tnt @Tim Edwards BTW, did you adapt all the cells including `in_s` and `in_c` ? Just to make sure I can also use those 😅 [2025-11-26 7:36 p.m.] rtimothyedwards_19428 Yes. All digital cells are 3.3V compatible. {Reactions} 👌 [2025-11-26 8:00 p.m.] rtimothyedwards_19428 @tnt: The LVS issue is due to a wayward "DVSS" label that got lost and wandered off and stuck itself to the ASIG5V pad. [2025-11-26 8:11 p.m.] rtimothyedwards_19428 I finally found the source of the label, hiding in the LEF file, under the sofa cushions. [2025-11-26 8:47 p.m.] 246tnt Yes, I saw that in the LEF already, I was about to update the issue on github 😅 [2025-11-26 8:47 p.m.] 246tnt Still have some other LVS issue but that'll have to wait a bit. [2025-11-26 8:50 p.m.] rtimothyedwards_19428 I have confirmed that fixing the LEF caused the virtual short in the magic view to disappear. It has been pushed. {Reactions} 👌 [2025-11-26 9:49 p.m.] 246tnt Ok, yeah, remaining LVS is because one net gets extracted as `\IO_CORNER_NORTH_WEST_INST.DVSS_RING_uq0` and in the netlist it's `\IO_CORNER_NORTH_WEST_INST.DVSS_RING` and that causes port mismatch. [2025-11-26 9:49 p.m.] 246tnt manually fixing that up and running netgen on the result checks out just fine. [2025-11-26 9:50 p.m.] rtimothyedwards_19428 If that's a top-level port then you can avoid the unique name by doing `extract unique notopports`, which was how I got the SRAM to pass LVS. [2025-11-26 9:54 p.m.] 246tnt Yeah, although technically they should be connected internally and not rely on any external connections. [2025-11-26 9:54 p.m.] 246tnt if I use that option, it wouldn't check if they are connected or not. [2025-11-26 9:55 p.m.] 246tnt I mean, if all the DVSS nodes were not connected somewhow, it wouldn't spot it. [2025-11-26 9:56 p.m.] rtimothyedwards_19428 One way to get around it is just to copy enough of the connection between them inside the top level cell that magic sees that they are connected within the top level. Magic does extraction on each individual cell without looking at what's in subcells that might be connecting things together. Modifying that behavior is probably a lot of work. {Reactions} 👍 [2025-11-26 11:39 p.m.] mithro_ Please do report segfaults upstream - OpenROAD should *never* segfault. [2025-11-27 1:43 p.m.] 246tnt `21154 KLayout DRC errors found.` @Tim Edwards 😢 [2025-11-27 2:42 p.m.] rtimothyedwards_19428 @tnt : I assume those errors are coming from the I/O pads? Can you send me the layout and DRC results? I made many small changes to the I/O layouts, but they are still the same pads apart from swapping in a level shifter circuit in front of each digital pin. However, I read in the I/O GDS and regenerated it from magic, so a single missing output layer or incorrect rule could have a massive effect. [2025-11-27 2:42 p.m.] 246tnt Lots of them are more due to marker layers causing different rules to apply. [2025-11-27 2:42 p.m.] rtimothyedwards_19428 Presence or absence of marker layers? Did I manage to drop some ESD marker mask? [2025-11-27 2:43 p.m.] 246tnt Absence. Of ESD and Latchup. And then some Resistor marker layer added instead. [2025-11-27 2:44 p.m.] 246tnt Let me create a reproducible. [2025-11-27 2:44 p.m.] rtimothyedwards_19428 Okay. I'll need to regenerate them with mask hints for the marker layers. I don't think it's going to be a huge effort. [2025-11-27 2:45 p.m.] rtimothyedwards_19428 This is the "dirty" part of "quick & dirty". [2025-11-27 2:48 p.m.] 246tnt ``` klayout -b -zz -r ${PDK_ROOT}/gf180mcuD/libs.tech/klayout/tech/drc/gf180mcu.drc -rd input=/mnt/pdk/OL2/pdk_root/gf180mcuD/libs.ref/gf180mcu_ocd_io/gds/gf180mcu_ocd_io.gds -rd report=drc.klayout.lyrdb -rd feol=True -rd beol=True -rd conn_drc=True -rd wedge=True -rd run_mode=deep -rd thr=16 -rd topcell=gf180mcu_ocd_io__bi_24t ``` {Reactions} 👍 [2025-11-27 2:49 p.m.] 246tnt this runs the DRC on only `gf180mcu_ocd_io__bi_24t` and will show the errors. [2025-11-27 2:49 p.m.] 246tnt I mean obviously you need to check all the cells, but that's a good start 😅 [2025-11-27 2:49 p.m.] 246tnt And runs much faster than a full chip DRC [2025-11-27 3:39 p.m.] rtimothyedwards_19428 @tnt : Where are you getting the file `gf180mcu.drc` from? I don't have that in my PDK. [2025-11-27 3:41 p.m.] 246tnt @Tim Edwards Ah, from https://github.com/wafer-space/gf180mcu [2025-11-27 3:42 p.m.] 246tnt I think it's just a top level calling all the rules deck. Probably on @Leo Moser (mole99) 's growing list of stuff to upstream 😅 [2025-11-27 3:45 p.m.] mole99 Exactly 😁 [2025-11-27 3:50 p.m.] rtimothyedwards_19428 That file belongs in https://github.com/fossi-foundation/globalfoundries-pdk-libs-gf180mcu_fd_pv {Embed} https://github.com/fossi-foundation/globalfoundries-pdk-libs-gf180mcu_fd_pv GitHub - fossi-foundation/globalfoundries-pdk-libs-gf180mcu_fd_pv Contribute to fossi-foundation/globalfoundries-pdk-libs-gf180mcu_fd_pv development by creating an account on GitHub. 2025-11_media/globalfoundries-pdk-libs-gf180mcu_fd_pv-6EC75 {Reactions} 👍 [2025-11-27 3:51 p.m.] mole99 First I need to merge: https://github.com/wafer-space/gf180mcu/pull/1 and ensure there aren't any regressions. [2025-11-27 3:53 p.m.] rtimothyedwards_19428 Is that file written in ~~rust~~ ruby? I'm getting `ERROR: Can't run macro (no interpreter)` but I think I don't have ~~rust~~ ruby enabled in my version of klayout. [2025-11-27 3:54 p.m.] mole99 It's written in ruby, perhaps that is missing? [2025-11-27 3:54 p.m.] rtimothyedwards_19428 I meant ruby, sorry. I thought rust was wrong, somehow. [2025-11-27 3:55 p.m.] 246tnt All klayout drc are written in ruby AFAIK [2025-11-27 3:57 p.m.] 246tnt I can run drc for each cell and post results if that's easier but I thought it'd be better if you could validate changes yourself [2025-11-27 4:11 p.m.] rtimothyedwards_19428 Posting results might be _quicker_ because I'm going to have to recompile klayout with ruby support. But I did a layer-by-layer comparison between an original 5V I/O cell and my modified one, and I think I understand where I'm missing layers. Some of my generated layers (DUALGATE, for example) are not the same size as the original but are probably still valid. The main issue seems to be the missing "latchup" and "ESD" marker layers. Both are just two rectangular areas under the pad, and easy to add with mask hints. There is another issue with all FETs being marked as 5V due to the fact that the I/O library was created before I modified the handling of 5V/6V cells, but that's easy enough to correct and probably doesn't make a difference anyway. [2025-11-27 4:40 p.m.] 246tnt Arf, sorry for dissapearing ... went to grab a drink, knocked something over and spent the last 30 min cleaning up my mess 😅 [2025-11-27 4:40 p.m.] 246tnt Running DRC now. [2025-11-27 4:47 p.m.] 246tnt {Attachments} 2025-11_media/drc.tar-81A4F.bz2 [2025-11-27 4:47 p.m.] 246tnt @Tim Edwards {Reactions} 👍 [2025-11-27 5:17 p.m.] rtimothyedwards_19428 More work than I was expecting but shouldn't be too big of an issue. {Reactions} 👌 [2025-11-27 7:37 p.m.] 246tnt BTW, if there is anything I can do to help, I'd be happy to 🙂 [2025-11-27 8:00 p.m.] rtimothyedwards_19428 I may need to you run more klayout DRC checks. But I need to get some updates pushed, first. I have worked through most of the main errors already. Fortunately the highest _count_ of errors was in the array contact spacing, which was easy to fix (although it exposed a way to get around magic's generation of wider-spaced 4x4-and-up arrays, which is to stack 4 or more 1xN contact arrays next to each other, which then magic no longer sees as a single "large array"). {Reactions} 👍 [2025-11-27 10:22 p.m.] rtimothyedwards_19428 @tnt : All right. I think I have a good handle on all the issues. I will push everything to the repository along with updates to open_pdks and everything should be ready to retest in the morning. I may have missed one or two things but nothing looks like it can't be dealt with pretty easily. I do have to rethink the way I handle generating PPLUS and NPLUS around tap diffusion that is too close to an nwell edge, but I think I have methods now that will work right that weren't available when I originally wrote the GF180MCU tech file. I haven't tested them yet; instead I just made sure that all tap diffusion is well away from nwell edges. It seemed like everything in the I/O library was just slightly closer than the limit that triggers the extra overlap (0.43um). [2025-11-27 11:19 p.m.] mithro_ @Tim Edwards - If you have docker installed you can get a docker container with the precheck with all the deps and PDK and everything. [2025-11-28 1:03 a.m.] rtimothyedwards_19428 @tnt : I have updated the PDK and the I/O library. I don't know if I managed to get everything, but it should be a lot cleaner than before. [2025-11-28 6:55 a.m.] 246tnt @Tim Edwards Indeed, it seems much cleaner now 🙂 [2025-11-28 6:56 a.m.] 246tnt {Attachments} 2025-11_media/drc.tar-E2AD0.bz2 [2025-11-28 6:56 a.m.] 246tnt only fillnc and bi_24t still have items. [2025-11-28 7:18 a.m.] 246tnt I was looking at this extra overlap limit in the DRM and quite confused because on the diagrams that 0.43um is measured from the "inside" edge !?! [2025-11-28 7:18 a.m.] 246tnt {Attachments} 2025-11_media/2025-11-28_377x360_scrot-B65BC.png [2025-11-28 7:25 a.m.] 246tnt Just had a look at the exact errors and `filllnc` is just false positive because the cell can't be used by itself, it's too narrow but when put in the ring, there should be no errors ( although the `pr boundary` seems too wide ? ) And the `bi_24t` is minor issues with nplus/pplus extension but trivial to fix with maskhints. [2025-11-28 10:47 a.m.] 246tnt @Tim Edwards Som in `bi_24t`, one of the issue is ... probably a bug in magic or somewhere because if I load the `.mag` and do `gds write gf180mcu_ocd_io__bi_24t` , then there is the issue, like this : [2025-11-28 10:47 a.m.] 246tnt {Attachments} 2025-11_media/2025-11-28_874x440_scrot-DE1E5.png [2025-11-28 10:47 a.m.] 246tnt Then I don't do anything else, but just re run the same `gds write` command and then the issue isn't there and the gap was bridged. [2025-11-28 10:47 a.m.] 246tnt {Attachments} 2025-11_media/2025-11-28_919x492_scrot-9FABD.png [2025-11-28 10:56 a.m.] 246tnt The other one I fixed with this : ```diff diff --git a/magic/comp018green_out_paddrv_6T_PMOS_GROUP.mag b/magic/comp018green_out_paddrv_6T_PMOS_GROUP.mag index 98627ee..6a58925 100644 --- a/magic/comp018green_out_paddrv_6T_PMOS_GROUP.mag +++ b/magic/comp018green_out_paddrv_6T_PMOS_GROUP.mag @@ -3272,4 +3272,6 @@ use PMOS_metal_stack PMOS_metal_stack_6 timestamp 1758724778 transform 1 0 809 0 1 496 box -44 0 1584 12000 +<< properties >> +string MASKHINTS_NPLUS 12251 -768 12331 14372 << end >> ``` [2025-11-28 10:56 a.m.] 246tnt but maybe you have a more elegant way of preventing it in the first place 😅 [2025-11-28 2:41 p.m.] rtimothyedwards_19428 @tnt : Yes, that's where the nwell needs to be extended out to 0.43um to prevent the little stub of NPLUS from showing up. The algorithm I came up with to deal with the extra overlap of NPLUS or PPLUS for diffusion edges close to an nwell edge works fine except when the diffusion is just slightly less than than the 0.43um limit away from the edge. Obnoxiously, most of the nwells in the I/O cells have been drawn just slightly under this limit, which then unfortunately highlights where my algorithm doesn't work right. [2025-11-28 2:43 p.m.] rtimothyedwards_19428 Yes, I've looked at that illustration before and decided it's an error in the illustration (one of many). [2025-11-28 2:55 p.m.] 246tnt I have a new chip-wide precheck running ATM, hopefully it will be clear. [2025-11-28 3:38 p.m.] rtimothyedwards_19428 I made a few edits so that the tap diffusion is wide enough that the NPLUS and PPLUS overlap of contacts is the same width as the overlap of the diffusion, so the NPLUS and PPLUS form simple rectangles that don't need to be hierarchically checked to close up gaps between the shapes. There was plenty of room to extend the taps outward and I should have done that earlier, just for the sake of the layout being cleaner. So there will be one more round of updates and the I/O pads should be squeaky-clean by tomorrow. I still need to rework the algorithm that generates the too-thin diffusion artifacts, but at least the errors only show up in pathological cases. [2025-11-28 3:57 p.m.] 246tnt Ok, hopfully it will show up in a `ciel` release and I can use that to do the final build. [2025-11-28 4:25 p.m.] 246tnt It cleared the KLayout DRC deck. Got some magic DRC errors from the pre-check but I suspect it's because the tech file isn't up to date. [2025-11-28 4:30 p.m.] rtimothyedwards_19428 I didn't change the tech file on this round. The DRC errors look like something that pops up after a GDS read, but I can reproduce them, so I'll take care of them. [2025-11-28 4:31 p.m.] rtimothyedwards_19428 No, actually I think I just cut a corner and made the last several changes without running on drc(full), so totally my fault. [2025-11-28 4:34 p.m.] 246tnt I still had the tech file from a while back. [2025-11-28 4:34 p.m.] rtimothyedwards_19428 It was an nwell spacing error? [2025-11-28 4:34 p.m.] 246tnt Yes and also some via width < 0.28u [2025-11-28 4:35 p.m.] 246tnt `Via3 width < 0.28um (V3.1 + 2 * V3.4)` `MV N-well spacing < 0.74um (NW.2a)` `Via4 width < 0.28um (V4.1 + 2 * V4.4)` [2025-11-28 4:42 p.m.] rtimothyedwards_19428 The nwell spacing is due to a tiny notch in an nwell and I'm fixing it now. The via3/via4 errors are more bothersome---I'm guessing that they come from the same issue in the corner cell where some via rows were spaced close enough together that they get merged by magic, but the rows are slightly offset so they produce slivers that are narrower than the contact after the merge. But there seems to be some intermittent behavior there, because a few days ago I was fixing those, and after fixing all the errors I saw, I would re-write the GDS, and after reading the GDS back, the errors would appear again, somewhere else. It was like sometimes it would merge the rows and sometimes it wouldn't. I thought I had finally fixed the errors once and for all, but apparently not. The error would not be from the tech file, it would be from the corner cell itself. [2025-11-28 4:44 p.m.] rtimothyedwards_19428 Arrgh, yes, I can see them. . . [2025-11-28 10:51 p.m.] mithro_ I would really love to create some improved documentation with actually useful GDS examples (which can be rendered into diagrams) of these things which are unclear. [2025-11-29 8:45 p.m.] 246tnt {Attachments} 2025-11_media/drc_in_s.klayout-162CD.lyrdb 2025-11_media/drc_in_c.klayout-C61D6.lyrdb 2025-11_media/drc_bi_t.klayout-99BA4.lyrdb 2025-11_media/drc_bi_24t.klayout-3EB84.lyrdb 2025-11_media/drc_bi_a.klayout-24AB6.lyrdb [2025-11-29 8:46 p.m.] 246tnt @Tim Edwards Errors in NP from the latest cells. [2025-11-29 8:46 p.m.] 246tnt (sorry to be the bearer of bad news 😅 ) [2025-11-29 10:00 p.m.] rtimothyedwards_19428 @tnt : No problem, iterate until done. Apparently I did not check the output after my last edit (sloppy or sleepy, not sure which. Or sloppy because of sleepy). Otherwise I would have seen that. I just forgot to add 0.02um to the top of the nwells. . . Sorry for forcing another round. [2025-11-29 10:01 p.m.] rtimothyedwards_19428 I also still need to figure out why magic won't cleanly separate the VSS and DVSS when extracting the corner cell, because that's preventing a clean LVS on anything using the padframe. [2025-11-29 10:24 p.m.] rtimothyedwards_19428 Now it's suddenly showing a property error in magic, but I think that's related to something that Mitch already pointed out to me, and it's a problem in magic that I need to look into. It's not a problem in the layouts. [2025-11-30 1:48 a.m.] mithro_ Too much turkey? 🙂 [2025-11-30 1:54 a.m.] rtimothyedwards_19428 @tnt : I got klayout recompiled with ruby support, so I should be able to run the DRC myself from now on. I just needed a little time away from the openframe project to get the compile done. [2025-11-30 2:10 a.m.] rtimothyedwards_19428 @tnt : Also: Confirmed that the I/O cells are finally DRC clean. [2025-11-30 2:11 a.m.] rtimothyedwards_19428 @Tim 'mithro' Ansell : I had duck, not turkey. The wild turkeys have been wandering around my property recently. I guess they know it's safe here. [2025-11-30 2:15 a.m.] mithro_ The google campus in MTV had the occasional wild turkey wandering around it. ============================================================== Exported 100 message(s) ==============================================================